מעולה.
מאוד אהבתי את השימוש בgithub (אני מקווה שגם אתה אהבת).
הוראות התקנה ברורות ופשוטות עם עימוד אסטטי וקריא.

פחות אהבתי את הקונסטנטות. אין שום סיבה שהפריימוורק ייצר במקומי קונסטנטות שאני גם רוב הסיכויים לא צריך.
בכלל אני אישית ממש לא אוהב קונסטנטות גלובליות, אבל גם הקונסטנטות הקיימות לא בהכחך צריכות להיות קיימות. אלו הם קונסנטות שהפריימוורק צריך, לא המשתמש של הפריימוורק.
(בין היתר גם קונסטנטות שלא מופיעות ברידמי: SMARTY_DIR וכו)

כל הכבוד על שימוש ב autoloader ו iterator. קונצפטים טיפה יותר מתקדמים ממומשים בצורה מעולה.
כנ"ל לגבי מימוש של אינרפייסים מובנים, array access ו iterator aggregate
חבל שלא הכל משתמש ב autoloader ובכלל יש איטרציה של קבצים בתיקיות כדי לטעון אותם.

סחטן על השימוש בקלאסים אבסטרקטיים איפה שצריך.
קצת פחות טוב השימוש ב access modifiers שמשאירים הרבה דברים למשתמש שהוא לא באמת צריך.
(אני בקונטרולר שלי לא צריך את הפונקציה invoke, את param או את actions)

השמות של המטודות והממברים שפוטים וברורים. זה אחד האתגרים של המתכנתים ועברת אותו בצורה טובה מאוד.

יש גם דוגמה הפוכה לשימוש נכון בקונסנטים בתוך מחלקות. ששם השימוש מעולה. חבל שלא בכל המחלקות יש שימוש בקונסנטים של מחלקה ויש הרבה מאוד מקומות שהמילה request או page או param פשוט מופיעות hard coded כמה פעמים ברצף.


בסה"כ עבודה יפה.
תוכל לקחת אותה צעד אחד קדימה על ידי שימוש בניימספייסים

1) תודה
2) אז מה לעשות במקום זה? אני הוסיף את SMARTY_DIR לדוקומנטציה :)
3) תודה:)
4) יכול להיות שאני אשנה את זה, כרגע אני דווקא מרוצה מאופן הטעינה. המשתמש בכלל לא צריך להשתמש בפונקציות להכללת דפים (כי הוא הרי לא אמור ליצור שום קובץ חוץ קונטרולרים, טמפלטים ומודלים).
2) אני אהפוך את invoke לprivate. את Params צריך כדי לקבל קלט (דרך שורת הכתובת, אני אוריד את השילוב עם $_REQUEST), והactions זה מה שהלקוח בונה.
5) לא הבנתי את הערה האחרונה.
6) אולי אשתמש בניימספייסים בעתיד.
תודה רבה על המשוב המפורט, מאד אהבתי באופן כללי את האתר יש פה רמה ועזרה תודה רבה :)

2. פשוט למחוק את כל הקונטסנות. למה הם צריכות להיות שם? תכניס אותם לאיזה קונסנטות של מחלקה פנימית שלך וזהו. המשתמש הסופי ממש לא צריך אותם.
2. במקום params הייתי מעדיף לקבל אותם בתור פרמטרים של פונקציה לקונטרולר
5. על קונסטנטות של מחלקות? אפשר להגדיר קבועים ששיכים למחלקה מסויומת ולא לכל הפרוייקט. ככה.
בכיף. הרמה נוצרת לא על ידי "האתר" אלה על ידי מי שכותב בו מדריכים ושואל\עונה לשאלות.

2. ליצור מחלקת Framework בIndex.php?
2ב. כאילו הם יועברו בתור פרמטר לaction?
5. אני יודע מה זה, יש לי את זה גם בפריימוורק... לא הבנתי למה התכוונת.

2ב. כן. בדומה ל-mvc ב-asp.net.

ב-index.php הייתי שם את ה-bootstrap. אתחול של הפריימו'ורק. לא הייתי שם שם מחלקה.

2ב. למה בעצם? מאיזה סיבה לעשות את זה
ligh - לא עושים ככה.

תשמע, אתה לא יכול להגיד פשוט "לא עושים ככה". קח את לארוול בתוך דוגמה - הוא פועל בדיוק ככה.

אתה עף על לרוול יותר מדי...
יש עוד דרכים אחרות.
בכל אופן, יש לך סקייפ?

אני אשמח מאוד אם לא כל שיחה שלנו תכלול עקיצות. ונתתי את לארוול בתור דוגמה, כי אני לא מכיר פריימו'ורקים אחרים. כן, יש לי. תנחש. :-) הכינוי הוא lighto273

אני מציע לך בקשה, וזאת לא עקיצה - מה נראה לך אני חושב שאני רואה דבר כזה בבלוג שלך :
"
קח רגע, הבט בקוד המקור הזה. מחייך לא ראית טופס כה נקי. אמור את זה בקול לעצמך. קדימה, אני אחכה.

מעולם לא ראיתי טופס כל כך נקי.
אתה צודק, זה יפהפה. בוא נעיף מבט על קוד המקור של הטופס שנוצר כדי לוודא שאני לא סתם מלמד אותך משהו שגוי, אתה יודע, בשביל הכיף?
"

אני מעולם לא הייתי כותב דבר כזה. זה מתורגם. XDDD
עריכה:
אם כי אתה בהחלט צודק שלא כתבתי שזה מתורגם במאמר הספציפי הזה. בדיוק הוספתי.

יש עוד הערות?

הייתי ממליץ לכתוב דוקומנטציה מפורטת יותר... אבל זה הכול. לפי מה שראיתי, זה מושקע ומעולה. :-) (מובן שעדיין יש דברים להוסיף וכדו', אבל זה כבר משהו אחר.)

תודה אוראל, אלכס הצעתי למשתמש שנקרא intval בסקייפ, תאשר אותי :)

יש עוד משהו?

נזכרתי בזה עכשיו כי אני עובד על משהו משלי.

בתור מישהו שמשתמש ב-framework, אני הייתי שמח לקבל את מה הפרמטרים של הבקשה כפרמטרים ל-action. משהו כזה:

ככה שאם אני גולש אל index?age=17&name=idan אני אקבל Hello idan, you are 17 years old.
*שים לב שסדר הפרמטרים שנשלחו בבקשה לשרת ממש לא משנה.

דבר נחמד עוד יותר יהיה לקבל object mapping:


ככה שאם אני אגלוש ל-index?username=idan&password=qwerty אז אני אקבל: idan:qwerty.

תוכל לראות איך אני מימשתי את זה: https://github.com/iiddaannyy/webhub

דבר ראשון יש לי מספיק שכל כדי לממש דברים כאלה פשוטים בעצמי.
בנוגע לרעיון הראשון - אפשרי, אבל למה לא להשתמש במה שאני סיפקתי? איזה יתרון יש לשיטה שלך?
רעיון השני - אפשר, אבל שוב פעם - יש לך מחלקת InputRequest, שמכילה את כל הinput שהתקבל (לא פרמטרים דרך הURL). אם אתה רוצה משהו אתה מוזמן. מחלקת Form יכול להיות שתהיה בהמשך.

אם לא הייתי חושב שאתה יכול לממש דברים כאלה בעצמך לא הייתי מציע. אבל אתה כהרגלך בזמן האחרון אוהב לתקוף. שיהיה.

1. לא הבנתי מה סיפקת? אתה מדבר על inputrequest? לפי מה שראיתי שם אתה גם מכניס את הנתונים שהתקבלו בעוגיות. ולרוב זה לא משהו שאני ארצה בתור כותב אפליקציית אינטרנט לקבל כל הזמן. ל"שיטה" שלי (היא לא שלי, האמת היא שהעתקתי את הרעיון מ-asp.net mvc) יש יתרון בכך שהיא נקייה יותר. בהסתכלות על ה-action אתה רואה מה הוא מצפה לקבל כבר מכותרת המתודה. ובתוך המתודה אתה עובד עם הפרמטרים וזה מאוד נוח.

2. אם אתה לא מממש את הרעיון הראשון אז אין בכלל מה לדבר על הרעיון השני. הרעיון השני הוא נוח הרבה יותר כשמדובר בטפסים או בפרמטרים שמייצגים אובייקטים מסוימים. לפעמים במקום לקבל id של משתמש אני ארצה לקבל אובייקט Member ואז ישר לעבוד עם האובייקט.
זה בכלל הרבה יותר נוח כשאתה מממש ולידאציה של אובייקט בקוד שלך ואז כל הבדיקות המעיקות נחסכות. ככה שאני אוכל לעשות משהו כזה:

תראה איזה יפה ונוח זה. במקום לקבל username בנפרד ו-password בנפרד ולבצע בדיקות מעיקות על הקלט, אני מקבל את זה כאובייקט LoginForm שבתוכו כבר מכיל את בדיקות התקינות שצריך לבצע כהערות. כל מה שלי נשאר זה להפעיל את המתודה valid שתעבור על ההערות של כל ה-properties ותדאג לבצע בדיקות ואלידציה עבורי ואני מקבל פשוט true או false האם הפרטים שהוכנסו בטופס תקינים.
גם את הרעיון הזה, אגב, גנבתי מ-asp.net רק ששם זה הרבה יותר טוב עם פירוט של כל שגיאה (שלשם גם אני מכוון) ועם DataAnnotations.


וכנראה לא הבנת אותי נכון, לא רק הפרמטרים של הכתובת מועברים כפרמטרים ל-action, אלא גם פרמטרים שלא הועברו דרך הכתובת (נאמר בשיטת POST).

1) לא נגעתי בעוגיות (רק בסיישנים, וגם זה רק במחלקה ייעודית) בכל הפריימוורק.
2) אני אממש את זה, אבל איך להבחין בין פרמטרים מrequest לבין פרמטרים משורת הכתובת?
ולא תקפתי אף אחד, אל תחרחר ריב.

1. ב-inputRequest אתה משתמש במערך REQUEST_ כדי להחזיר את הנתונים. המערך הזה מכיל בתוכו גם את העוגיות.

2. GET - משורת הכתובת. POST - מהבקשה. אבל כל הקטע הוא שלא צריכים להבחין. כי אם נסתכל על הדוגמה למעלה שהבאתי עם name ועם age אז לא משנה אם זה דרך POST או GET. יכול להיות שהבקשה היא מסוג POST ונשלח רק name אבל דרך הכתובת שלחו את age (כך שהוא יימצא במערך GET_$) וזה עדיין יעבוד. כל הקטע הוא לבצע merge בין המערכים GET_$ ו-POST_$.

"דבר ראשון יש לי מספיק שכל כדי לממש דברים כאלה פשוטים בעצמי." נשמע כאילו אתה מאשים אותי בכך שאני מתנשא כי נתתי לך דוגמה לאיך אני מימשתי את זה. אבל יכול להיות שטעיתי אז עזוב את זה.

הכל טוב. :)

הגיוני, אני אשנה את זה בהמשך. אולי גם הוסיף את האפשרות השנייה. יש לי כרגע כמה צרות ככה שזה לא בטווח הקרוב מאד. בכל אופן לי זה היה נשמע מעט כמו התנשאות, אולי בגלל שהעצבים שלי מתוחים גם ככה, מתנצל מראש.

הכל בסדר.

חג שמח ובהצלחה עם מה שזה לא יהיה. :)

פרמטרים משורת הכתובת הם לא GET, אלה הפרמטרים המגיעים מהראוטר. וגם לעשות כמו שאמרת דורש שימוש בreflaction class, שמאט את הפריימוורק. כרגע זה לדעתי בסדר, השיטה שלך יותר מתקדמת אבל משלמים בביצועים... פה אני מעדיך לחסוך, במיוחד שזה לא כזה קריטי. אני מניח (השערה, לא מעבר) שבDot Net ממשים את זה באופן יעיל שאי אפשר לעשות בPHP. עוד סיבה למה להעדיף את C#...
ASP NET MVC וכל הפיצ'יפקס שאפשר להוסיף (Linq, Entity framework וכו') לוקחים את PHP בכיס הקטן, אבל אני מרגיש שעדיין לא מיציתי את PHP.

דרך אגב, הדגש בפריימוורק זה הlibs, למרות שכרגע זה לא נראה מרשים.

ReflectionClass הוא לא היחיד שנעשה בו שימוש.
בכל מקרה הדגש במה שאני בונה הוא הנוחות והקלות לכתוב קוד. גם אם מדובר בעוד חצי שנייה של הרצת הסקריפט.

לילה טוב. :-)

אני דורש - פחות מחצי שנייה. XD

בשביל זה יש הרבה פריימוורקים. :)
בחלקם הקוד ירוץ מהר מאוד וביעילות רבה, ומנגד לך יהיו חיים מעט יותר מאתגרים כמתכנת.
בחלק אחר תוכל להנות מהקלות המדהימה של הפיתוח אבל אתה תשלם קצת בזמן הריצה.
ובאחרים תמצא שילוב של נוחות ומהירות. הם לא יהיו הכי מהירים ולא יהיו הכי נוחים, אלא שילוב.

אי אפשר להנות מכל הדברים. כשאתה מנסה לממש דברים שמטבעם לא קיימים ב-php עם php (כמו named parameters שיש ב-c# אבל אין ב-php (הרעיון הראשון שהצעתי כאן)), אתה נהנה מנוחות בקוד אבל משלם קצת בזמן ריצה.

ככה כל עולם התכנות עובד. תוכל לכתוב ב-assembly ותתאמץ בפיתוח אבל תהנה מביצועים גבוהים. או שתבחר לכתוב בשפה גבוהה יותר, להנות בנוחות וקלות יחסית לכתוב קוד אבל לקבל ביצועים מעט יותר פחותים.

וכאן גם יש שיקול נוסף, כי מעבר לנוחות בכתיבת הקוד אתה גם עושה את זה בפחות זמן. כלומר זמן הפיתוח מתקצר. וזה שיקול מכריע בחברות היום ולכן לא תראה חברות שמפתחות משהו וכותבות אותו ב-assembly אלא אם יש צורך ממשי.

:)

אבל יש גבול - האתר ממש יהיה איטי אם נשתמש גם ברפלקשיין וגם בORM ובסוף לאתר סביר נצטרך לטעון 2-3 שניות. לאתרים גדולים זה יפיל לך את הסרבר. פשוטו כמשמעו. הקטע פה שאני עומד להשקיע בו זה הפינוק של libs - המון libs מאורגנים ומסודרים להמון מטרות. גם לקבל את זה כמערך לא נראה לי איזה משהו מאתגר במיוחד. סתם פחות נוח (ולא כזה פחות נוח). השיטה הזאת נחמדה, אבל התשלום גדול מדי... וכמו שאמרתי מטרת הפריימוורק הוא לפנק בlibs.

ההבדל לא יהיה כל כך מורגש מצד המשתמש. עם עבודה נכונה (כמו שימוש נכון ב-buffering ושליחת הפלט גם בחלקים ועבודה עם cache אולי) ההבדל יהיה זניח ביותר.
ולאתרים גדולים יש שרתים גדולים ככה שזו לא בעיה.

בכל מקרה, כמו שאמרתי - הפריימוורקים השונים הם לא העתקה אחד של השני. לכל אחד יש את הצדדים הטובים יותר והטובים פחות ולכן צריכים לדעת במה בוחרים בהתאם לצרכים.

הפתרון הנפוץ לדברים כאלה הוא "לקמפל קוד". הקוד PHP שאתה כותב, הפריימוורק בהרצה הראשונה מייצר מחדש אבל בצורה יותר אופטימלית לזמן ריצה. ובפעמים הבאות משתמש רק בו.
שני הפרוייקטים הכי פופולאריים שעושים ככה הם Twigו- Symfony frawerok

@intval
לא כל כך הבנתי על מה אתה מדבר (אני חושב שכן הבנתי חלק, אבל אני לא בטוח שאני יודע בדיוק למה התכוונת).
אשמח אם תתן איזו דוגמית או תרחיב את ההסבר. :)

PHP מקמפלת קוד PHP בעצמה לקוד יותר יעיל זה רעיון נחמד, אבל אמרתי כבר שלדעתי זה לא מספיק חשוב כל העניין הזה. למה זאת צריכה להיות כל כך בעיה שהמתכנת בעצמו ישתמש ב$this->params['foo'] ולא ב$foo? למה שלא ישתמש בעצמו ב LoginForm::validateUsername? הרי זה דברים כל כך פשוטים וטריוויאלים, אבל מצד שני למכונה זה מבזבז זמן לעשות את זה. הרעיון שלך אלכס הוא רעיון מצוין ברמה גבוהה, אבל אני אגיד את האמת - אני לא יודע כמה זמן יקח לי לממש דבר כזה ברמה גבוהה באמת, אבל עיף לי ל"הזניח" את המתכנת עם האופציות כרגע ולהקדיש את זמני לפיתוח libs ברמה.